<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Roadmap: How to Adopt the Iterative Development Practice</title>
<meta name="uma.type" content="Roadmap">
<meta name="uma.name" content="how_to_adopt">
<meta name="uma.presentationName" content="How to Adopt the Iterative Development Practice">
<meta name="element_type" content="other">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="_bpWt8OMPEdyM47cGD2jiaQ"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Roadmap: How to Adopt the Iterative Development Practice</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/roadmap.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This roadmap describes how to adopt the iterative development practice. It helps an organization get prepared for developing and delivering software incrementally.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><h3>
    Getting started
</h3>
<p>
    Iterative development is based on the idea that a software system is built iteratively in a series of increments. Each
    increment adds a subset of the final system's functionality, and the system grows to become more and more complete over
    the course of the project's iterations.
</p>
<p>
    Consider making all of your iterations have the same duration. This is important for two reasons: it establishes the "heart
    beat" of the project, and it helps understand the project team's performance. This supports the creation of successively
    more accurate estimates of remaining work. Attack the hardest problems on the first iterations, but do not overload the
    first iteration too much. Make sure that you can show progress at the end of each iteration. Do not extend an iteration in
    order to finish work, but also do not finish an iteration without any software to be demonstrated. If needed, break the problem
    into smaller, more manageable pieces so that this balance can be achieved.
</p>
<p>
    Plan an iteration in detail only when it is due to start. Each iteration starts with an iteration planning
    meeting with the whole project team. In this meeting, the objectives of the iteration are defined in terms of work
    items, tasks are identified for these work items, and team members sign up for tasks and provide their estimates. At
    the end of the iteration planning meeting, the iteration plan is comprised of a set of work items, decomposed into
    tasks that individual team members sign up for. The iteration can be started. Once an iteration is under way, it should
    be allowed to proceed according to its plan, with as little external interruption as possible.
</p>
<p>
    During the course of the iteration, team members provide frequent status of their tasks in focused meetings. The
    frequency of these meetings is decided by team: it could be daily, a couple times a week, or weekly. Team members work
    on the tasks they signed up for, following the appropriate priority. Allow detailed informal peer coordination to
    happen, and mark completed work items in the iteration plan. The overall iteration status is hence readily available in
    the iteration plan at all times. Any work items that have not been justifiably completed by the end of the iteration
    are removed from the iteration and re-assigned to the next one (or just returned to the work items list).
</p>
<p>
    Make all iterations follow the same pattern. This helps the team to focus on activities that are specific to the
    beginning, middle, and end of an iteration. For example, some common activities performed during an iteration are:</p>
<ul>
<li>Iteration planning</li>
<li>Iteration architecture work</li>
<li>Continuous development of micro-increments</li>
<li>Creation of stable weekly builds</li>
<li>Bug fixing</li>
<li>Iteration review and Retrospective</li>
</ul>	
	<p>See <a class="elementLink" href="./../../../practice.mgmt.iterative_dev.base/guidances/concepts/iteration_lifecycle_B16552E2.html" guid="_DI_tICNaEdyCq8v2ZO4QcA">Iteration Lifecycle</a> for more information.
</p>
<h3>
    Common Pitfalls
</h3>
<p>
    There are common pitfalls experienced when adopting an iterative approach, including the ones listed in the following
    sections. Fore more information on challenges when transitioning from waterfall to an iterative development approach,
    see <a class="elementlinkwithusertext" href="./../../../core.default.nav_view.base/guidances/supportingmaterials/references_C6FF2A8D.html#KRU00" guid="__nHToFndEd2EdJKkAyeBng">[KRU00]</a>.
</p>
<h4>
    What project managers should plan for
</h4>
<p>
    One of the most difficult situations for project managers is to transition from a traditional development approach
    (such as waterfall) to an iterative approach. There is more planning with iterative development than with waterfall: one
    plan per iteration. At every iteration, there is negotiation with stakeholders, changes in scope, and re-planning.
    Project managers need to avoid detailed planning upfront, and should work with their best estimates for the tasks at
    hand in a given iteration. </p>
	<p>
	However, this behavior should not result in unplanned and non-prioritized requirements
    creating scope-creep, nor unnecessary rework happening on elements that are not broken. The iteration plan, with iteration
    objectives and planned tasks, should be collaboratively created by the project manager, the team, and stakeholders in order
    to promote a common understanding and buy-in into what is expected at the end of an iteration.
</p>
<h4>
    Which comes first: specifications or software? 
</h4>
<p>
    In a waterfall approach, progress is often measured by the completion of specifications. For example, if the design
    specification is completed and signed-off, the team advances to the implementation based on the design specification.</p>
<p>    
	With iterative development, artifacts evolve throughout the iterations, and every iteration should result in an
    increment in the capabilities offered by the solution: in other words, implemented, tested software that is able to be
    demonstrated (and potentially shipped) to customers. Software comes first. Planning is more important than the plans.
    Designing and architecting an evolving solution is more important than capturing and polishing design and architecture
    models. At the end of each iteration, perform an assessment to gauge the completion of requirements that have
    passed test cases. Another way to make significant progress is by focusing on the harder problems (or risks) as
    early as possible, thus making sure that you create and use a sound, executable architecture as the basis for the other
    requirements.
</p>
<h4>
    Different iterations for the different disciplines
</h4>
<p>
    A common problem found in organizations moving from a waterfall to an iterative process is that they use the iteration
    concept only as an "envelope" for their engineering disciplines. For example, it is common to hear people in those
    organizations talk about "requirements iteration" or "test iteration". A fundamental tenet of iterative
    development is that it takes a holistic view of work items: each work item assigned to an iteration is completed in
    that iteration. For example, a "Login User" work item would see all required tasks (such as design, code, and test) to
    complete that work item. At the end of the iteration, the Login User behavior can be demonstrated as an integral part of
    the executable system.
</p>
<h4>
    No visible progress
</h4>
<p>
    Some teams will have work items that are not completed during an iteration as expected, and will not report problems.
    This creates a false impression that work items planned for the iteration are being closed, thus showing an inaccurate
    iteration burndown.<br />
    In order to avoid this, monitor active tasks closely, and address any slippage promptly. Use frequent, short status
    meetings to gauge progress and detect issues. Create a "no blame" environment where everyone feels empowered by the
    team and actively seeks advice and help from the team.
</p>
<h4>
    Adding work to an ongoing iteration
</h4>
<p>
    Management or stakeholders may impose more work to be added to an on-going iteration. While this is sometimes
    legitimate (for business reasons), there is a risk that this work just gets informally accepted by the team, without
    passing through the Work Items List, where it gets prioritized with the remaining work.<br />
    In order to minimize the impact of new work being added to an iteration, make sure to involve stakeholders in the
    planning process, so that they understand the impact a new work item brings to the current iteration. Be prepared to
    negotiate the removal of lower priority work from the iteration, in order to accommodate the new requested work.
    Another approach is to convince stakeholders that in a few weeks the iteration will end (with demonstrable progress),
    and that the new work item can be prioritized and assigned to the next iteration.
</p></td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright"><p> This program and the accompanying materials are made available under the<br />
  <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse 
  Public License V1.0</a>, which accompanies this distribution. </p><p/><p> <a class="elementLink" href="./../../../core.default.release_copyright.base/guidances/supportingmaterials/openup_copyright_C3031062.html" guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a></p></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
